wo 01/04851 ^ PCT/AUOO/00833 

IMPROVED APPARATUS FOR REMOTE PAYMENT TRANSACTIONS 

The present invention relates to a method and 
apparatus for controlling remote payment transactions, and 
particularly, but not exclusively, to a remote payment 
terminal for facilitating payment transactions and to a 
method of controlling the terminal. 

Devices for carrying out remote payment transactions 
are well-known. These "payment terminals" include EFTPOS, 
credit card payment terminals, etc. 

The function of such remote payment terminals is to 
facilitate payment transactions. Goods/services will 

usually be offered by the payment terminal holder. The 
payment terminal provides message information to a 
"transaction acquirer" (which may be a bank) to enable the 
transaction acquirer to settle the transaction. Message 
information may also be provided to determine whether the 
person who owns the card has sufficient funds to enable the 
transaction. A transaction usually takes place by means of 
a card, such as a credit card or a debit card. 

A payment terminal may, for example, provide for the 
following basic operations: 

(1) Input of information which is required to enable 
a transaction eg. identification of the card holder's 
account. The information is most often read from a 
magnetic stripe on a credit card or bank card or the like, 
or a smart card. In addition to reading details from a 
card a PIN number or the like code may also be required, 
for security purposes. 

(2) Obtain access to the users account. This is 
usually done by remote communication with a processing 
device holding the person's account data, usually on bank 
premises and remote from the payment terminal. Usually, 
the information on the person's account input to the 
payment terminal will need to be transmitted for 
verification and to enable access to the account. Also a 
money amount will usually need to be input to the payment 
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terminal and transmitted over the communications line. At 
least some and perhaps all of the transmitted data may be 
encrypted for security purposes and the payment terminal is 
therefore, in such a case, required to have means (3) 
5 providing for encryption. 

(4) The payment terminal may need to be able to 
receive communications over the remote line from the 
processor accessing the user's account, ie. to provide an 
"answer" to the payment device regarding the user 

10 transaction. The answer may include information that an 
account debit /credit has taken place (eg. EFTPOS) or merely 
an approval that the user has enough money in his account 
to enable a transaction (some credit card payment 
terminals) . Again, this transmitted information may be 

15 encrypted and, if so, will require translation (5) in the 
payment terminal . 

(6) To provide a message that the transaction request 
is approved or that a transaction has occurred, by display 
or printer, for example. 

2 0 These basic operations can be carried out in number of 

different ways, governed by the hardware/software 
combination of the brand of payment terminal and the 
requirements of the owner of the payment terminal . The 
payment terminal owner is usually an account acquirer such 
25 as a bank. Different account acquirers generally have very 
different requirements for operation of their payment 
terminals. For example, they will generally have differing 
requirements for the type and operation of encryption for 
communications. They would also generally have different 

3 0 requirements for the display and formatting of any 

"receipt" to be printed out for the customer. Also, 
communications protocols may be very different from bank to 
bank. The format of data storage on an account holders 
card generally varies quite widely from bank to bank as, 
3 5 indeed, may the content of the data on the account holders 
card. 
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To date, various account acquirers have usually 
directed a manufacturer of payment terminals to manufacture 
a terminal in accordance with their requirements. Thus, 
there are many different brands of payment terminal, 
operating different varieties of hardware and software in 
order to satisfy the various requirements of the various 
account acquirers . Not only account acquirers may require 
tailored payment terminal operation, but requirements may 
be dictated by goods/service providers who operate the 
terminals at the "front end", eg. retail chains. 

An important requirement for payment terminals is that 
they must generally ensure that communicated information is 
secure, usually by way of encryption. Security must also 
be provided to govern access to accounts. Often the 
payment terminal will include security information such as 
one or more "secret keys" which facilitate secure 
communications and ensures that access to an account can't 
be obtained in error or fraudulently. 

Because these devices are required to deal with 
security sensitive information, it is a requirement that 
these devices be thoroughly tested before they are allowed 
to be used, in order to ensure that they operate correctly 
and no errors are likely to be made, particularly with the 
security sensitive information. Such testing can take many 
man hours and is therefore quite expensive. It is 

nevertheless absolutely necessary and devices will not be 
allowed to be used which have not been "certified" as 
complying with all security and operational requirements. 

Because of the need to ensure that operation of the 
payment terminal does not cause any security risk, any 
software change which may be required by an account 
acquirer requires the entire terminal and software to be 
completely retested to ensure compliance. Any change, 
therefore, is extremely expensive because of this need for 
testing and also because it is necessary to reprogram the 
terminal in each case. Another problem with payment 
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terminals is that because of the way the terminal is 
established, i.e., by being manufactured and tested with 
software and hardware for one particular account acquirer 
who is the owner of the terminal, a terminal has a 
5 '"primary" relationship to the owner ("primary") account 
acquirer. The primary account acquirer will essentially 
dictate the nature of the operation of the terminal and 
will select the software operation to be carried out by the 
device. Although the primary acquirer may well take into 

10 account some of the needs of other acquirers whose accounts 
may also be accessed via the terminal, there will be a 
natural reluctance on behalf of the primary acquirer to 
meet all the other acquirers operational needs. After all, 
the primary acquirer will usually be in competition with 

15 the other acquirers. Further, even if the desire were 
there for the primary acquirer to meet the other acquirers 
needs in detail, expense of changes, mainly due to it 
being necessary to test the entire terminal and software 
for certification purposes, is another disincentive. The 

2 0 cost involved in making any changes is great, and therefore 

the primary acquirer is likely to be reluctant to do so. 

Thus, the primary acquirer will usually program a 
device in a way in which suits them rather than other 
acquirers. This and other factors lead to a lot of 
25 "^back-end" processing. Rather than dealing with acquirers 
requirements in the software and arrangement of the 
terminal device itself, processing is carried out by 
computers at the ''back-end". For example, all 

communications from the payment terminal for all account 

3 0 acquirers may be routed to a processing system at a primary 

account acquirer. The processing system at the primary 
account acquirer then further processes the information and 
may send further communications to other account acquirers 
in order to process a transaction. These acquirers may 
3 5 have their own processing systems carrying out further 
processes This '"back-end" processing leads to an increase 
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in cost for the consumer. 

The present invention provides a system for 
controlling remote payment transactions, comprising a 
remote payment terminal including processing means and an 
5 operating system arranged to carry out a remote payment 
transaction operation in accordance with application 
instruction means, an application memory means storing the 
application instruction means for operation of the payment 
terminal, the arrangement being such that application 
10 instruction means is independent of the rest of the payment 
terminal . 

By ''independent" is meant that the application 
instruction means can be handled as a separate entity. For 
example, they may be able to be altered and tested 
15 separately from the rest of the payment terminal . They may 
also be able to be provided to the system separately from 
the rest of the payment terminal . A common payment 
terminal may thus be able to handle a number of different 
sets of application instruction means, provided 

2 0 independently. 

Preferably, any change in the application instruction 
means can be carried out without it being necessary to re- 
test the other software and/or hardware of the terminal, by 
applying the present invention. 

25 Preferably, the application instruction means (usually 

in the form of software) is stored in a separate memory 
means, preferably a separate memory module. The memory 
module may be of the "plug-in" variety arranged to plug 
into the payment terminal - or may be stored on a "smart 

30 card" . Where the application instruction means is stored 
on a smart card, a smart card reader is preferably provided 
with the payment terminal to enable the application 
instruction means to be read to the payment terminal 
operating systems . 

3 5 In a payment processing system utilising the present 

invention, therefore, each account acquirer may preferably 
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provide its own application instruction means stored on a 
memory module, such as a smart card. A particular 
application instruction means will be selected when the 
respective account acquirers system is to be accessed, eg 
5 when a user of that acquirers accounts system wishes to 
make a payment transaction via the remote payment 
transaction terminal. 

Preferably, if the application instruction means is on 
a smart card or the like, when a user swipes their magnetic 

10 card or smart card the remote payment terminal is arranged 
to call for the particular account acquirers application 
instruction means, and the vendor (i.e payment terminal 
operator) will then load the terminal with the particular 
account acquirers application instructions, in one 

15 embodiment by reading the account acquirers smart card 
containing the particular application instruction means - 

Different account acquirers can therefore conveniently 
implement different processing requirements for their 
accounts systems by providing different application 

20 instructions. These application instructions may govern 
all aspects of the remote payment transaction including 
communications, i.e. the remote payment terminal may be 
directed to communicate with the particular account 
acquirers "host" terminal. 

25 Because the application instruction means can 

preferably be tested separately from the payment terminal, 
it is not necessary to go to the expense of retesting the 
entire payment terminal and operating system merely for an 
applications upgrade for a particular account acquirer. 

3 0 Application changes and upgrades can therefore be 
implemented relatively cheaply. A payment terminal 

arranged to receive the application instruction means in 
this form can be termed a "universal" terminal. The 
operating system and payment terminal may only need to be 

35 tested and certified once. Applications may then be 
provided separately, and also tested separately. 
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Preferably, security of data can also be included in the 
memory module, for controlling the security for each 
particular acquirer. 

Different applications may be provided for the same 
5 account acquirer. For example, the account acquirer may 
require different applications for different types of 
account it administers, eg credit card accounts, current 
accounts, etc. Present invention preferably facilitates 
the provision of as many different applications as may be 
10 required. 

An alternative to providing application on separate 
memory modules is to provide a universal terminal having a 
partitioned memory with secure memory address locations for 
loading application instruction means for particular 
15 account acquirers. Application instruction means could 
then be uploaded by telecommunications, i.e data transfer 
on-line . 

In the prior art, generally one account acquirer 
controls transactions with all the other account acquirers. 

2 0 With use of the present system, however, it would be 

possible for each acquirer to control its own transactions, 
as each acquirer may provide separate application 
instructions . 

In a preferred embodiment, an arrangement in 
25 accordance with the applicants co-pending International 
Patent Application Number PCT/AU98/00173 may be utilised. 
This co-pending application describes a generic software 
arrangement which is particularly suitable for remote 
payment transaction processing and which can be adapted to 
30 run on different hardware architectures. 

Any other "open" software system may be used and 
applicants invention is not limited to that disclosed in 
PCT/AU98/00173 . 

Another feature of the present invention, is that in 

3 5 some cases the memory module may preferably include memory 

locations for storing details of transactions which have 
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taken place over a particular time period (eg on a day by 
day basis) . The memory module can then be returned to the 
account acquirer, eg. at the end of the day, so 
transactions can be processed. This will be most 

5 convenient where the memory module is a smart card. This 
arrangement does not require any on-line communications 
between the account acquirer system and the remote payment 
terminal . 

By "operating system" we don't necessarily mean an 

10 operating system as is conventionally understood i.e. an 
operating system arranged to control hardware and 
peripherals in accordance with application commands. While 
it includes such a basic operating system, it is also 
envisaged that the operating system in the payment terminal 

15 may also include commands which enable it to interface with 
the application instruction means and may also include more 
sophisticated "high level" commands for controlling 
operation of a remote payment transaction. 

For example, the application instruction means may be 

2 0 a set of instructions arranged to control merely the 
aspects of operation of the terminal which are required to 
be varied from account acquirer to account acquirer. 
"Application" instructions, in this case, will also be 
included in the operating system, for controlling aspects 

2 5 of operation of the terminal which are common to all 
acquirers . 

Preferably, therefore, a payment terminal device is 
developed and tested separately from application software 
for running the device. Different payment terminal devices 

30 in the present invention, including the basic payment 
terminal operating system and software (''fixed program") 
may be certified to carry out a number of applications and 
the fixed program may include a list of options that the 
device is certified for. Any application software being 

35 run on that particular device will, preferably, first check 
whether device is suitable for running all the options 
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available in that particular application software module. 
It may only run a limited number of the options available, 
or the device may be arranged to run all the options. 

On the other hand, the fixed program of the device is 
5 preferably arranged to register the application software 
(external) software and determine what cards it can 
process. Both the device and the application software may 
be able to determine whether to or not they are compatible 
and if they are, exactly what operations can be run. 

10 The remote payment terminal, therefore, preferably 

includes a fixed program which includes instructions for 
controlling the terminal to access application software 
from a separate memory area and control the payment 
terminal to run in accordance with one, some or all of 

15 options and features which may be included in the separate 
applications software. Preferably, the applications 

program is arranged to assess the security of the device 
and what operations it is certified for, and then only to 
run the operations in the application software that the 

20 device is certified for. 

The present invention therefore preferably has the 
advantage that a plurality of ''generic" payment terminals 
can be provided. The generic terminals are certified by 
the account acquirers to run application software which is 

2 5 provided separately, preferably by the generic terminal 

being able to accept separate memory modules containing the 
software. The generic terminals can therefore be purchased 
by prospective users, e.g., merchants, as well as by 
account acquirers and the like. The user is then provided 

3 0 with the application software required for dealing with 

different account acquirers, by the provision of separate 
memory modules. Each application software module can be 
tested and certified separately from the device. 

As an alternative to providing separate memory 
35 modules, separate memory areas may merely be specified in 
the generic terminal for loading of the separate 
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independent application instruction means. 

The present invention further provides a remote 
payment terminal, comprising a processing means and 
operating system arranged to carry out a remote payment 
5 transaction operation in accordance with application 
instruction means, the operating system being arranged to 
access the application instruction means in a separate 
application memory means, and the remote payment terminal 
and operating system being arranged to be independent from 

10 the application instruction means. 

By '^independent" is meant that the remote payment 
te2rminal can be handled as a separate entity, and may be 
provided with a plurality of separate independent 
application instruction means to operate in accordance with 

15 those instructions. The remote payment terminal is 

preferably essentially generic to the plurality of separate 
application instruction means. Preferably, the remote 
payment terminal can be tested for compliance with 
predetermined requirements, separately from the application 

2 0 instruction means. 

Preferably, the operating system includes a fixed 
program which is arranged to interface with the application 
instruction means. The fixed program may, for example, 
include a list of applications which it is compatible with 
25 and on operation of the card by a user (e.g., to swipe a 
certain account acquirers bank card) . 

The present invention yet further provides an 
application memory means, storing application instruction 
means for instructing a remote payment terminal comprising 

3 0 a processing means and operating system, to carry out 

remote payment transactions in accordance with the 
application instruction means, the application instruction 
means being independent from the payment terminal and 
operating system. 
35 Preferably, the application memory means is a separate 

memory module and is preferably provided by way of a smart 
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card or the like. Preferably, security information may 
also be stored in the application memory means. In one 
embodiment, memory locations may also be provided for 
storing data on transactions. 

The present invention yet further provides a method of 
operating a remote payment terminal comprising a processing 
means and operating system arranged to carry out remote 
payment transactions in accordance with application 
instruction means, comprising the steps of providing the 
application instruction as an independent entity. 

Preferably,' the application instruction means provided 
from a separate application memory means. 

Preferably, the separate application memory means is a 
separate memory module, such as a smart card. 

The present invention yet further provides a method of 
arranging a remote payment transaction processing system, 
comprising the steps of providing a universal terminal 
which includes a basic set of operating instructions and 
hardware sufficient for carrying out remote payment 
transactions in accordance with application instruction 
means, separately providing independent application 
instruction means for instructing operating of the remote 
payment terminal to carry out remote payment transactions. 

Preferably the method also includes the step of 
separately testing the application instruction means for 
compliance with a remote payment processing system, 
separately from testing of the remote payment terminal. 

The present invention yet further provides a system 
for controlling remote payment transactions, comprising a 
remote payment terminal including a processing means and 
operating system arranged to carry out a remote payment 
transaction operation in accordance with application 
instruction means, and a separate memory module, such as a 
smart card, storing the application instruction means for 
instructing the remote payment transaction. 

Features and advantages of the present invention will 
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become apparent from the following description of an 
embodiment thereof, by way of example only, with reference 
to the accompanying drawings, in which; 

Figure 1 is a schematic diagram of a system for controlling 
5 remote payment transactions in accordance with an 
embodiment of the present invention, and 

Figure 2 is a diagram showing the architecture of the 
system of figure 1. 

Reference numeral 1 indicates a "universal" payment 

10 processing terminal in accordance with an embodiment of the 
present invention , 

The payment terminal comprises a central processing 
unit 2 which includes a memory, a microprocessor, and other 
hardware as would be known to a person skilled in the art, 

15 and an operating system for carrying out remote payment 
transaction operations in accordance with application 
instruction means. The terminal 1 also includes a smart 
card reader 3 connected to the central processing unit 1 
and a communications module 4 also connected to the central 

20 processing unit 2. The communications module 4 is used for 
communications with host computers of an account acquirer, 
to facilitate on-line remote payment transactions, as is 
well-known to persons skilled in the art. 

The terminal 1 also includes a printer 5 and a display 

2 5 6 for printing and displaying information on remote payment 

transactions, and a keyboard 7 for inputting data. 

Reference numerals 8,9 and 10 designate "smart" cards, 
each of which includes a memory module 8a, 9a, 10a which is 
arranged to store application instruction means for 

3 0 instructing operation of the terminal 1 to control remote 

payment transactions . 

This arrangement is very different from payment 
processors of the prior art, which incorporate the 
application instruction means directly within the terminal 
3 5 1, not separately on a separate memory module. 

In operation, when a customer requires a remote 
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payment transaction, the customer will be required to 
insert their account card, which may be a smart card, in 
the card reader. Note that the account card may 

alternatively be a standard magnetic card, and a magnetic 
card reader (not shown) may be provided, in which case the 
customer will swipe their card through the magnetic stripe 
card reader. The central processing unit 2 is arranged to 
detect that a card has been swiped and (or customer smart 
card read) and will then ask or require that an application 
instruction means be loaded. This may be done in a number 
of ways. For example, the display 6 may indicate which 
particular application instruction means is required by the 
CPU 2. Alternatively, a payment terminal operator may know 
from the customers card exactly which set of application 
instruction means are required. There are a number of ways 
in which the required application instruction means can be 
indicated. The next step is that the required application 
instruction means is loaded to the CPU 2 by inserting the 
card 8,9,10 into the card reader and downloading the 
application instruction means. Subsequently, the remote 
payment process may be carried out, in accordance with the 
application instruction means which have been downloaded 
for the customer. 

In a subsequent transaction requiring different 
application instruction means, then the terminal would 
require a different card 8,9,10 to be loaded into the card 
reader . 

There are a number of ways in which the application 
instruction means may be provided to the payment terminal 
1. Separate "plug-in" memory modules could be provided, 
which are not smart cards; application instruction means 
could be downloaded on-line and stored in a separate memory 
location in the central processing unit 2 . The important 
feature of the invention is that the application 
instruction means can be dealt with completely separately 
from the remote payment terminal. It is therefore 
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necessary only to test and certify the remote payment 
terminal itself once. Each time application instruction 
means require updating or modifying, because of the 
requirements of a particular account acquirer, for 
example, this can be done completely separately, and 
testing of the application can be done separately. 

Another possibility for providing the application 
instruction means may be on a customer card having a memory 
module for containing application instruction means, as 
well as having means containing the customer information 
and data. The card holder may therefore have a smart card 
which, as well as containing information for enabling a 
transaction with his account, also contains the application 
instruction means for operating a "universal" terminal. 

The memory module which separately contains the 
application instruction means may also preferably contain 
the security data for the particular account acquirer. 

Figure 2 shows an architecture for a preferred 
embodiment of the present invention. 

The payment terminal 1 incorporates an operating 
system 2 0 and hardware 21 (the hardware is described above 
with reference to Figure 1) . The operating system controls 
the hardware to carry out remote payment transaction in 
accordance with application instructions 23, 24 which are 
provided via a separate memory module as explained with 
reference to Figure 1 . The separate memory module also 
includes security data 25, 26. The payment transaction 
will also require information from the user card and other 
input information, such as a PIN (via the keypad 7) , as 
indicated by reference, 27. 

In accordance with a preferred embodiment, the 
architecture of the present invention utilises the novel 
software configuration described in applicants co-pending 
Application Number PCT/AU98/00173 , the specification of 
which is incorporated herein by reference. The operating 
system therefore comprises a fixed program including 
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virtual machine (VM) processors 30, comprising a message 
engine, a protocol engine and a function processor, forming 
a "virtual machine" for running generic application 
instruction means. The message engine is a separate 
5 virtual processor whose function is to deal with the 
assembly and disassembly of messages. The protocol engine 
is a separate virtual processor whose function is to 
organise communications . 

The present invention is not limited to utilising the 

10 virtual machine described in PCT/AU98/00173 . Any "open" 
software system could be applied. Virtual machines, which 
operate on different hardware are well-known in the art. 
Any software operating system may be used as long as the 
application instructions are compliant with the operating 

15 system. 

The fixed program also includes an interface 35 which 
is arranged to interface with application instruction means 
23, 24. The interface 35 may include a list or table of 
the applications which this particular device 1 is 

2 0 compatible with. On insertion and swiping of a user card, 

the type of application required is detected and the 
interface 35 will check the list and ask for the particular 
application if it is available, and if it is not available 
in this particular device 1 it will indicate that the 
25 transaction cannot be carried out for this particular user 
card. The interface 35 also preferably includes a list of 
options accessible by application instruction means 23, 24, 
indicating the features or options of payment transactions 
which the device 1 is capable of carrying out. The 

3 0 application instructions may include means for determining 

which of a number of options in the application 
instructions the device is capable of carrying out and only 
then running those options that the device is capable of 
carrying out. This arrangement takes into account the fact 
3 5 that over a period of time developments to applications may 
occur which may not be compatible with machines that were 
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developed some time ago. 

Variations and/or modifications may be made to the 
invention as shown in the specific embodiments without 
departing from the spirit or scope of the invention as 
5 broadly described. The present embodiments are, therefore, 
to be considered in all respects as illustrated and not 
restrictive . 



